1. Field of the Invnetion
The present invention relates to the management of lock resources using lock escalation in database management systems. More specifically, the present invention relates to the lock escalation method based on the new concept of the unescalatable locks, which improves performance by using semi lock escalation, lock blocking, and selective relief.
2. Description of the Related Art
First, we define some terminology needed for further description of the present invention.
A “locking” is a concurrency control method. In locking, a transaction has to acquire a lock before accessing the data item to insure the consistency of the database. The “lock granules” are the data aggregates that are atomically locked to insure consistency. Examples of the lock granules are databases, files, pages, and records.
The “multigranularity locking” is a method, that provides several lock granules in a DBMS to allow a transaction to determine lock granularity for itself. In this method, acquiring the lock on a higher-level granule is implicitly considered as acquiring the same lock mode on a lower-level granule.
Typical lock modes used for multigranularity locking are the shared(S), exclusive(X), and intention(I) modes. In the intention mode, we distinguish the intention shared(IS) mode and the intention exclusive(IX) mode. An S mode lock allows only read accesses to the data item locked, but an X mode lock allows both read and write accesses. An I mode lock indicates an intention to request S or X mode locks for the lower-level lock granules.
TABLE 1T: compatible, F; incompatible 
Table 1 represents the compatibility between lock modes. In Table 1, numerical no. 101 is the acquired lock mode, and numerical no. 102 is the requested one. We use the term “file” for the coarse granule and the term “record” for the fine granule to help readers understand the present invention.
Database management systems (DBMSs) have limited lock resources due to a physical limitation of shared memory. In most cases, the system administrator determines the maximum number of locks supported by a DBMS when he starts the DBMS. Thus, when locks are requested excessively at the same time, lock resources are exhausted, and then the transactions that are not able to secure locks should be aborted. This situation is “lock resource exhaustion”.
Lock resource exhaustion may cause a transaction to fall in “cyclic restart,” in which the transaction is repeatedly aborted and restarted, but is never given the opportunity to commit. In the worst case, all transactions could fall in cyclic restart and none of them commits. This situation is “live halt.”
Lock escalation is considered as a solution for this problem. Lock escalation consists of two steps: “lock conversion” and “lock release”. “Lock conversion” is the step for converting the mode of the lock on the file from IS to S or from IX to X. “Lock release” is the step for releasing all the locks on the records that belong to the file.
Now, we introduce the existing lock escalation methods. In UniSQL, Database Administration Guide (All Products), 1996. [Reference 1], lock escalation is executed when a transaction acquires record locks over the predetermined lock escalation threshold for a specific file. The same lock escalation threshold is applied to all the transactions and files. We call this method as “Lock Escalation Based on Locks per Transaction and per File (LETF).” LETF has the following problems.
First, it might execute needless lock escalation when a transaction acquires record locks over the threshold for a specific file even though there are extra lock resources available. In other words, lock escalation is needless since the possibility of lock resource exhaustion is low if there are few concurrent transactions even though a transaction acquires record locks for a specific file over the threshold.
Second, a transaction might not execute lock escalation because the number of locks requested is less than the threshold even when there are no more lock resources available. If many transactions execute concurrently, lock resources could be exhausted even though none of transaction requests locks over the threshold.
In IBM, IBM DB2 Universal Database Administration Guide, Version 6, ftp://ftp.software.ibm.com/ps/products/db2/info/vr6/htm/db2d0/index.htm, 2000. [Reference 2], a transaction selects one of the files it is accessing, and then executes lock escalation for that file when the total number of locks it requests goes over the lock escalation threshold regardless the file. The same lock escalation threshold applies to all transactions. This method has problems similar to those of LETF.
These problems can be potentially alleviated by allowing the transaction requesting a lock to execute lock escalation when there are no more lock resources available even though it has requested locks below the threshold.
Considering the total number of locks as in this method, however, does not solve the problem completely. When there are no more lock resources remaining, but the transaction is not able to execute lock escalation because of lock conflict, the transaction is aborted even though it is still possible that other transactions execute lock escalation instead.